Skip to content

Add REST plugin for user-defined policies #2631

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
May 23, 2025

Conversation

Nadine-H
Copy link
Contributor

@Nadine-H Nadine-H commented May 13, 2025

Resolves #2630.

Key notes:

  • The REST plugin is a builtin plugin, unlike how other plugins are defined and loaded in the dstack system.
  • The REST plugin has to be enabled through the dstack server config if the user wishes to hook up a plugin server.

@Nadine-H
Copy link
Contributor Author

Nadine-H commented May 14, 2025

Realized that setting up this plugin as an external package is unnecessarily complicating the installation process. I'm going to change it so that it's more builtin the server code.

@r4victor
Copy link
Collaborator

r4victor commented May 14, 2025

Realized that setting up this plugin as an external package is unnecessarily complicating the installation process. I'm going to change it so that it's more builtin the server code.

A good place for a built-in server plugins would be to put them in src/dstack/_internal/server/services/plugins/builtin/rest_plugin

May require renaming src/dstack/_internal/server/services/plugins.py to src/dstack/_internal/server/services/plugins/__init__.py

Let me know if you need help with refactoring.

@r4victor
Copy link
Collaborator

I'll create an openapi spec doc

@Nadine-H, Do you think of writing the spec manually or generating it automatically? Automatic generation is highly preferable because spec models are regularly updated with new properties and it won't be practical to maintain manually written spec.

@Nadine-H
Copy link
Contributor Author

I'll create an openapi spec doc

@Nadine-H, Do you think of writing the spec manually or generating it automatically? Automatic generation is highly preferable because spec models are regularly updated with new properties and it won't be practical to maintain manually written spec.

Automatic generation for sure. I set up a local FastAPI server to test the rest plugin and will share the openai.json with you shortly.

@Nadine-H Nadine-H marked this pull request as ready for review May 20, 2025 15:35
@Nadine-H Nadine-H requested a review from r4victor May 20, 2025 15:35
@Nadine-H Nadine-H changed the title Add REST plugin for pre-apply validations Add REST plugin for user-defined policies May 20, 2025
@Nadine-H
Copy link
Contributor Author

Adding documentation to the guides as well

@r4victor
Copy link
Collaborator

And regarding the documentation, I think we can generate the OpenAPI schema reference from the example plugin server and put it in the Reference->Plugins->Rest plugin similar to how the server OpenAPI is generated (https://github.com/dstackai/dstack/blob/master/scripts/docs/gen_openapi_reference.py). This could probably be done in a separate PR to limit the scope.

@Nadine-H Nadine-H requested a review from dakota-shop May 21, 2025 15:49
@Nadine-H Nadine-H requested review from r4victor and colinjc May 21, 2025 15:49
raise ServerClientError(f"{PLUGIN_SERVICE_URI_ENV_VAR_NAME} is not set")

def _check_request_rejected(self, response: SpecApplyResponse):
if response.error is not None:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically error: "" would cause a rejection; is that intended?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It shouldn't, I'll fix it and add additional tests for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@r4victor should we not allow empty strings and cause a pydantic ValidationError? or just treat it as a "no error" case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@r4victor I implemented the first option so that plugin developers are aware if they mistakenly set the error to "", but happy to switch to the other option if you prefer.

Copy link
Collaborator

@r4victor r4victor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I see some unresolved comments so if you're willing to address them, please do. I'm happy to merge once CI is passed.

@peterschmidt85 peterschmidt85 merged commit 3d5ab80 into dstackai:master May 23, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature]: Support REST-based plugins
5 participants